意図と可読性のあるtest codeを書く
個別的な分析手法とか、具体的なフレームワークには言及せずに
参考
テストコードに対する知識が少ないと、一番最初の悪い例が、そもそも「これ悪いんだ」という感想になるmrsekut.icon
変数にsut(SUT)やdoc(DOC)を使うことで、どの対象をテストしたいのかを明確にする prefixに付ければいい
これって割とOOP前提な話だよなmrsekut.icon
関数をテストしたいときって、関数それ自体がsutになるので、名前のつけようがない
テストケースではただ一つのことを検証する
細かくなってもいい
トータルとして冗長になってもいい
無理に簡潔に書こうとしなくていい
同じ前提を使うものは、同じ場所に書くことで、全体として簡潔にできる
振舞いに影響を与える値とそうでない値を区別する
テスト対象の関数の引数に対するワイルドパターン_的なやつを書くことで、どの引数をテストしたいのかを明確にする
生成メソッドを活用する
計算結果ではなく計算式を記述する
test codeを書くことで、元の実装の意図を伝える
こういう風に動くコードを書いた
このコードはこういう風に使う
こういう入力値を想定している
こういう時にエラーを返す
これ見れば全部詰まってる！というコード片をメモっておきたい
14章
よさそう